Cream of the Crop 1/Cream of the Crop 1.iso/PROGRAM/TP052492.ARJ/05-24-92.TPC

Text File | 1992-05-24 | 94KB | 2,865 lines

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       01-01-00 00:00:00
From
To
Subject


--- WM v2.01/92-0100
 * Origin: A.C.E. of Spades [phone] The B.A.N. board (1:116/33)
 * Tossed by SFToss v1.00b on 92/04/09  12:01:00

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 01:10:27
From       Mark Ouellet
To         All
Subject    Looking for frequable SHAZAM


Hi All,
        I'm looking for this file SHAZAM which is a Turbo
Vision program generator.

        If any one has this file up for Freq, from unlisted
nodes, please let me know.

        I know it's on Turbo-city but they only allow freqs
for FILES unless you are a member which I'm not.

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/17  14:37:26

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 05:20:38
From       Trevor Carlsen
To         Dj Murdoch
Subject    Re: Encryption of sorts.



 TC> function MakeCodeStr(key : longint; s: string): string;
 TC>     RandSeed := (key * len) DIV st[len];

 DM> Just so that you don't have unintended side effects, I'd save the old

 DM> RandSeed and restore it at the end of the routine.

I cannot think of why you would suggest this.  What possible side effects
are there?  As you know RandSeed receives a new value every time a call to
the Random function is made so any program relying on RandSeed to have a particu
ar value should save it itself.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/17  22:01:25

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 10:08:22
From       Trevor Carlsen
To         Florian Stupperich
Subject    HELP! CRT - Window() replacement



 FS> I am searching for a replacement of the CRT - WINDOW()
 FS> command ! I want to output the characters with the
 FS> WRITE/WRITELN command. Who can help me ? Who knows
 FS> such a procedure ? Please answer.

There is nothing that stops you from using write/writeln in a window.  In
fact that is all you can use if you want to remain inside the window co-ordinate
.  Perhaps I am misunderstanding what it is that you seek?

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/17  22:01:25

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 10:22:23
From       Trevor Carlsen
To         Greg Johnson
Subject    Re: Shelling To Dos



 GJ> {$M $4000,0,0}  (*Don't forget that second $ sign*)

The second dollar sign is irrelevant unless of course you particularly intend
it to be there.  Your message gives the impression that it is a requirement.
 It is not.  Your message also indicated that a previous message writer was
wrong in the advice he offered.  He was not.

Check out p272 in the Programmer's guide or type {$M in the IDE and press
Control-F1 for detailed information.

The following compiler directives are identical in their effect -

  {$M $4000,0,0}    and
  {$M 16384,0,0}

as $4000 (hex 4000) is equal to 16384.

TeeCee



--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/17  22:01:25

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 00:38:00
From       Norbert Igl
To         Roger Joelsson
Subject    16550 chip





 >> Turbo Powers Async Pro has a Unit that does this.  I don't think

 > Do you think I could f'req it from you? Please do send some net-mail
 > about this if it's OK..

   I think, you can't... its commercial...

 > (I'm in real need of such a 16550 detector, and I've searched here in
 > Sweden, and the above software doesn't seem to be available anywhere
 > here.)

  i've posted this a few day's ago, hmm, it's not so big (:-)

-------------------------8<---------------------------------

Const ComPortText : Array[0..4] of String[12] =
  (' N/A ','8250/8250B','8250A/16450','16550A','16550N');
      IIR     = 2;
      SCRATCH = 7;
Var   PortAdr : Array[1..4] of Word absolute $40:0;

function ComPortType(ComX:byte):byte;

BEGIN
  ComPortType:=0;
  if (PortAdr[ComX] =0)
  or (Port[PortAdr[ComX]+ IIR ] and $30 <> 0)
     then exit;                                         {No ComPort !}
  Port[PortAdr[ComX]+ IIR ] := 1;                       {Test: enable FIFO}
  if (Port[PortAdr[ComX]+IIR] and $C0) = $C0            {enabled ?}
  then ComPortType := 3
  else If (Port[PortAdr[ComX]+IIR] and $80) = $80       {16550,old version..}
       then ComPortType := 4
       else begin
       Port[Portadr[ComX]+SCRATCH]:=$AA;
       if Port [Portadr[ComX]+SCRATCH]=$AA              {w/ scratch reg. ?}
           then ComPortType:= 2
           else ComPortType:= 1;
       end;
END;

{ ...test...}
var com : byte;
begin
  writeln('COMPORT-CHIPTEST                 Norbert Igl,2:241/5300.3');
  for com := 1 to 4 do
    writeln(' Com',com,' chip type : ',ComPortText[ComPortType(com)]);
end.


Bye from Germany, Norbert

---
 * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
 * Tossed by SFToss v1.00b on 92/05/18  09:13:30

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 08:44:58
From       Dj Murdoch
To         David G. Edwards
Subject    Re: Procedures...

  >I don't understand this - why should exit procedures be
 > special?  Do you
 >think the same thing about unit initialization sections?

 DG> Symmetry.  In a program an Init proc may open files, so a
 DG> Done proc will close the files.  An exit proc to undo a
 DG> unit's initialization is entirely okay.

 DG> In the program I was discussing, the "assign" was in the
 DG> main part, so, IMO, the "close" belonged in the main part.
 DG>  If I hid the close in an exit proc, five months later
 DG> when looking at the code, I'd say, "Egads, I forgot to
 DG> close the file!"  Then add the close in main, and cause
 DG> the exit proc to fail.

 DG> I'm not dogmatic about it, and I appreciate your insight.

I think that your symmetry idea ends up with pretty much the same result as
my ownership idea.  I probably wouldn't get another component of the program
to open files if I was expecting my unit to close them, unless ownership were
specifically transferred.  So my programs end up pretty symmetrical, and I'd
guess your programs probably respect ownership, even if you never think about
it that way.

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/18  09:13:38

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 08:59:54
From       Dj Murdoch
To         David G. Edwards
Subject    Re: Pascal style #2

  >  IF (Y > 10)
 >    THEN X := 2
 >      ELSE X := 1;

 DG> It's correct that parens and indents promote clarity,
 DG> etc., but in real programs an indenting style like this
 DG> will quickly become unworkable.  I'm basing this on 6
 DG> years of maintaining a 60,000+ line Pascal program.
 DG> Please refer to Ledgard's _Professional Pascal_ (ISBN
 DG> 0-201-11776-2): he has an entire chapter on layout.

Could you give us some samples?  For example, how would Ledgard format the
fragment above?  I'd format it as

  if Y > 10 then
    X := 2
  else
    X := 1;

I think the people who capitalize keywords have it exactly backwards:  keywords
should be lower case, since they're just grammar.  Variable names should often
have leading capitals, since they're proper names.  (Some variables, like
loop counters, are essentially grammar, so I don't capitalize everything.)

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/18  09:13:38

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 09:08:33
From       Dj Murdoch
To         Mark Ouellet
Subject    Re: Help - Reading Records At

  MO> Jud,
 MO>         Seek DOES work on bytes if you declare your record to be of 1 byte

 MO> length.

I prefer using streams for this sort of thing, because you automatically get
a 1 byte record size, and error checking is easier.

You had:

 MO> BEGIN
 MO>     My_File_Name := 'Clients.dbf';
 MO>     ASSIGN(My_File, My_File_Name);
 MO>     RESET(My_File, 1);
 MO>                   {^ important}
 MO>     SEEK(My_File, 0);
 MO>     Bytes_To_Read := SIZEOF(One_Header);
 MO>     BLOCKREAD(My_file, My_Header, Bytes_To_Read, Bytes_Read);
 MO>     IF (Bytes_Read <> Bytes_To_Read) THEN BEGIN

I'd use:

  My_stream := New(PBufStream, init('Clients.dbf',stOpenRead, 2048));
  My_stream^.read(My_Header,sizeof(My_header));
  if My_stream^.status <> stOK then
    { handle the error }

The advantage of this approach (besides being a little shorter) is that it's
likely to be a lot faster:  you don't get buffered I/O on untyped files.

 MO>     { To get record 400 (Zero based) }

 MO>     Record_To_Get := 400;
 MO>     Bytes_To_Read := SIZEOF(One_Record);
 MO>     Offset_Of_Record := SIZEOF(One_Header) +
 MO>                         (Record_To_Get * Bytes_To_Read);

Watch out here - your Offset_Of_Record is going to be incorrect if it's out
further than 64K.  A safer calculation is

  Offset_of_record := sizeof(One_Header) +
                       LongMul(Record_To_Get*Bytes_To_Read);

A disadvantage is that streams and LongMul are only available in TP 6 and
later.


--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/18  09:13:38

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 09:17:47
From       Dj Murdoch
To         Shahar Prish
Subject    Re: Screen Save

  GG> Wouldn't this be just *Slightly* slow ? Something as the
 GG> following would be much much faster:

 GG> Var
 GG>   F:File;

 GG> Begin
 GG>   Assign (F,<filename>);
 GG>   {$I-} Rewrite (F); {$I+}
 GG>   If ( IOResult <> 0 ) then ErrorHandler;
 GG>   BlockWrite (F,Mem[$B800:0],4000);
 GG>   Close(F);
 GG> End.

 SP> Yes! U R right, only the q. seemed 2 come from some1 who
 SP> doesn't know PAS very well..

 No, he was wrong.  He opened the file with a record size of 128; he'll be
trying to write 128*4000 = 512000 bytes.  I think that'll overflow and turn
into the word value 53248, but it certainly won't do what he wanted.

That's why I avoid untyped files and BlockRead/BlockWrite.  It's just too
easy to make this kind of error, and a real pain to find.

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/18  09:13:38

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-17-92 09:24:42
From       Dj Murdoch
To         Gordon Tackett
Subject    Re: Multiple Constructors/Destructors

  > There's an obscure, but very serious, problem with
 > nested constructors. It's VERY important to use
 > ObjName.Method rather than just Method, when the
 > default constructor calls the general constructor.

 GT> This is very true but I don't think that it is in the
 GT> manual (I looked and couldn't find it). I was aware of
 GT> this but just didn't talk about the draw back in the message.

It's there, but not where you'd expect it.  Look in Chapter 17, in the Construct
rs and Destructors subsection.  It's p. 230 in my manual.  I've been told
it doesn't appear at all in the German translation of the manual.


--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/18  09:13:38

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 01:21:55
From       Trevor Carlsen
To         Josh Lippy
Subject    Re: The function "pos"



 TC> function UpString(Mixed: string): string;
 TC>   var L : byte;
 TC>   begin
 TC>     UpString[0] := Mixed[0];
 TC>     for L := 1 to length(Mixed) do
 TC>       UpString[L] := UpCase(Mixed[L]);
 TC>   end;

 JL> It's not good to assign the value to the function until the
 JL> end of the function, therefore it would be better to use a
 JL> tempstr and assign upstring to tempstr outside of the loop.

I'm willing to listen to arguments on your reasoning but just making such
a statement without a reason does nothing to convince me! Why is it not good?

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/18  20:17:45

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 01:25:18
From       Trevor Carlsen
To         Josh Lippy
Subject    Re: Unix Style timestamp



 JL> Give me a break, stop ragging on the only guy that was ever
 JL> able to come up with a working Unix date converter.  It's
 JL> not how he programs, it's that he takes the time to share it
 JL> with the rest of us.

There has been at least 3 and possibly 4 different people post working Unix
date units here in the echo at various times.  Brian Stark's unit was one
and a good one at that.  My comments were purely suggesting an improvement
to it.

If you are looking for more units and can't find others, just yell...

TeeCee


--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/18  20:17:45

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 01:53:11
From       Trevor Carlsen
To         Jud Mccranie
Subject    Re: Pascal Style #2



 TC> I would normally choose the second method, although there are
 TC> occasions when a third method is preferable.

 JM>  TC>   x := succ(ord(y > 10));

 JM> I think the third method is not desirable.  It happens to
 JM> work in this case, due to the way I chose the numbers, but
 JM> it will rarely work.

Can you give a case where it does not work?  Obviously if you want values
other than 1 or 2 for x it cannot work as written although the modification
is trivial.  I don't recommend using it across the board but there are some
instances when it is the best.

 JM> PS, is my origin line OK now?

Yep... fine.  Thanks.

TeeCee



--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/18  20:17:45

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 01:59:16
From       Trevor Carlsen
To         Roger Joelsson
Subject    Help Needed with TP arrays



 TC> Thearray : array[0..max] of byte;
 TC> *if* max is not a constant.

 RJ> I wonder if, or better said, how this would work... As far
 RJ> as I know, the only way of creating dynamically allocated
 RJ> memory is via pointers to varibles. (But then, though, we
 RJ> aren't talking about indexed arrays any more) Does anyone
 RJ> know if Turbo Pascal has the ability to create dynamically
 RJ> allocated arrays? (C has the _malloc and _calloc function,
 RJ> but TP??)

The above was to illustrate that dynamic allocation using standard methods
will not work. However the fix is simple, just declare the array as [0..0],
allocate the required memory via GetMem and do your own range checking as
normal range checking must be disabled.

Another, some say better, way is to declare the array to maximum allowable
size but only allocate the required memory - again by GetMem.  Program range
checking remains essential as normal range checking will not catch errors.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/18  20:17:45

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 02:05:36
From       Trevor Carlsen
To         Roger Joelsson
Subject    Rename



 RJ> Of course, you could also use the Reset procedure to check the
 RJ> existance of the file... i.e.:

 RJ> Function Exists (FileName : String) : Boolean;
 RJ> VAR
 RJ>    FileStr : Text;
 RJ> BEGIN
 RJ>      {$I-}
 RJ>      Assign (FileStr, FileName);
 RJ>      Reset (FileStr);
 RJ>      Exists := IOResult = 0;
 RJ>      Close (FileStr);
 RJ> END;

 RJ> This function would return True if the file exists or false when the

 RJ> file isn't there.

Not quite true...   It would also return false if the file existed but was
write protected, either by SHARE or by attribute.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/18  20:17:45

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 07:46:02
From       Dj Murdoch
To         Joshua Kersey @ 930/22
Subject    Re: blah...

 DM> Just treat your .EXE as a resource file, and store the .PCX files DM> each
as separate resources.  It's fairly painless.

 JK> Wow...that simply bewildered me. I've tried doing it
 JK> before with the .BGI's but never got it to work. Could you
 JK> give me an example?

Sure, I'll try.  Only problem is, I've got no idea what a .PCX file is like,
so whatever I come up with is probably way off.  I'll assume they're less
than 64K.  Watch out, though, the code below might not even compile.

 type
   PPCXpicture = ^TPCXpicture;
   TPCXpicture = object(TObject)
    { some fields here that are necessary for decoding - maybe size, pixel

      depth, that sort of thing. }

     size : word;
     data : pointer;

     constructor init(filename:string);
     { Reads a .PCX file into memory }

     constructor Load(var S:TStream);
     { Loads a .PCX file from a stream or Resourcefile or .EXE }

     procedure Store(var S:TStream);
     { Stores a .PCX file to a stream, etc. }

     destructor done; virtual;

    { Whatever other things you might want to do to the picture. }
  end;

{ You need to register types to use them on Resource files.  Here's
  the info: }

const
  RPCXpicture : TStreamRec  = (Objtype: 1001;
                               VmtLink: Ofs(TypeOf(TPCXPicture)^);
                               Load:    @TPCXPicture.Load;
                               Store:   @TPCXPicture.Store
                              );


  constructor TPCXpicture.Init(filename : string);
  var
    S:TBufStream;
  begin
    S.init(filename,stOpenRead,2048);   { Open the file with a 2048 byte
                                          buffer }
    if S.status <> stOK then
      fail;
    size := S.GetSize;
    if Size > 65521 then
      writeln('Can''t load files that big! Redesign me.');
    getmem(data,Size);
    S.Read(data^,size);
    S.done;                             { Closes the file }
  end;

  destructor TPCXpicture.done;
  begin
    freemem(data,size);                 { Clean up our allocation }
    TObject.done;                       { Call the parent destructor }
  end;

  procedure TPCXpicture.Store(var S:TStream);
  begin
    { first write the size, and any additional fields you've added }
    S.write(size,sizeof(size));

    { next write the data }
    S.write(data^,size);
  end;

  constructor TPCXpicture.Load(var S:TStream);
  begin
    if not TObject.Init then            { Call the parent init; often this
                                          would be TParent.Load }
      fail;
    S.read(size,sizeof(size));
    if maxavail < size then
      fail;
    getmem(data,size);
    S.read(data^,size);
  end;
   Okay, that's the basic setup.  Now, to move one into your .EXE file, you
just do the following:

  var
    EXE:TResourceFile;
    PCX:PPCXpicture;
  begin
    { Register our type. }
    RegisterType(RPCXPicture);

    { Open the current .EXE as a buffered stream, and pass it to the resource
      file. }
    EXE.init( New(PBufStream,
                  init(paramstr(0), stOpen, 2048)));

    { Read one into memory }
    new(PCX,load( 'mypic.pcx' ));

    { Store it in the .EXE with the name "mypic" }
    EXE.put(PCX, 'mypic');

    EXE.done;    { Close the .EXE }

To read one from your .EXE, use the same declarations, register the type,
open the .EXE, and then:

   PCX := EXE.get('mypic');

That's all there is to it!


--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/19  08:58:30

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 08:20:02
From       Dj Murdoch
To         Bruce Ruona
Subject    Re: Compression

  BR> Speaking of your streams unit...Grin...
 BR>
 BR> I just picked up a copy of it the other day, Primarily for
 BR> the compression ability, however, I was disappointed that
 BR> yours suffers from the same problems I've found in 99% of
 BR> the compression source codes I've looked at, namely
 BR> lacking the ability to store more then one archive per
 BR> file.  For example, using your stream unit to COMPRESS
 BR> test.lzw *.pas {I Believe I have the syntax correct there?}
 BR>
 BR> I haven't had much of a chance to play with this, but how
 BR> hard would this be to add?  seems to me all that would be
 BR> necessary is adding header containing appropriate
 BR> compression information (name, date, crc, size etc?)
 BR> previous to storing the actual resultant compressed
 BR> file-or am I way off base here (Possible since I just
 BR> started messing with streams and other such oddities in
 BR> the past month or so 8-)

First of all, you're much better off to use an archive utility than my compressi
n code if you want to make archives.  Why rewrite code that others have spent
a long time perfecting?  You'll find that PKZIP and the other modern archives
do better compression than the TLZWfilter does, and they've solved all the
problems of putting multiple files into an archive.

But if you're determined to do it yourself, you've got the right idea.  Write
out an uncompressed header for each file, then turn on compression (by init'ing
a new TLZWFilter) and copy the file into the archive.  How hard this would
be would depend on how fancy you wanted it to be.  ARC and ZIP files are pretty
careful to make sure you can recover some of the files if part of the archive
file is damaged; that requires some forethought - you have to be able to recogni
e a header when you come into the file in the middle somewhere.

You also have to worry about the typical operations that people will want
to do on archives:  delete one file, add one file in the middle, "freshen"
a set of files, etc.

Compression is obviously a key part of an archive utility, but there's a lot
more to them too.

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/19  08:58:30

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 08:30:10
From       Dj Murdoch
To         Trevor Carlsen
Subject    Re: Encryption of sorts.

  TC> function MakeCodeStr(key : longint; s: string): string;
 TC>     RandSeed := (key * len) DIV st[len];

 DM> Just so that you don't have unintended side effects,
 TC> I'd save the old
 DM> RandSeed and restore it at the end of the routine.

 TC> I cannot think of why you would suggest this.  What
 TC> possible side effects are there?  As you know RandSeed
 TC> receives a new value every time a call to the Random
 TC> function is made so any program relying on RandSeed to
 TC> have a particular value should save it itself.

What I was thinking of is this:

  I randomize, and generate ten random numbers.
  I encrypt something.
  I generate ten more random numbers.

If the encryption routine messes with Randseed, and the thing I encrypt is
the same in every run of the program, then the second group of random numbers
will always be the same in every run.  If I call Randomize after the encryption,
they'll probably be the same as the first group, at least on a fast machine.



--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/19  08:58:30

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 08:42:44
From       Dj Murdoch
To         Kevin Higgins
Subject    Re: Another oddity of TP 6.0!

  KH> When you forget the single quotes around the string to
 KH> search for in the FindFirst procedure, TP 6.0 will give
 KH> you an "Unexpected end of file" error.
 KH> (eg., FindFirst(*.*,0,sr); instead of FindFirst('*.*',0,sr);)

Nice one!  That's not a bug though.  The problem is that "(*" begins a comment;
the compiler thought that your whole program following FindFirst was a big
comment, and was surprised when it hit the end of file before you closed it.

The error message could be a little more informative, couldn't it?


--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/19  08:58:30

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 08:52:25
From       Dj Murdoch
To         John Kessel
Subject    Re: Reading in boot-sector

  JK> Who knows how to read in the boot-sector the offsets 39
 JK> untill 42 (27 untill 2A).

 JK> This contains the serial-number from a diskette.

To read the boot sector of a floppy disk, you need to use the DOS absolute
disk read service (INT 25h) or the BIOS disk read service.  Watch out - Intr
doesn't work with INT 25h, because it's a far procedure, not an interrupt
service routine.

But you can get and set the disk serial number without touching the boot sector
directly.  DOS gives you access, using AX=440D, BL=drive number, CH=08, CL=46h
(set) or 66h (get).  DS:DX should point to a record of the form

  type
    parmblock = record
      info_level : word;  { always 0 }
      serial_number:longint;
      volume_label :array[1..11] of char;
      filesystem   :array[1..8] of char;
    end;

I hope this helps.

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/19  08:58:30

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 09:05:14
From       Dj Murdoch
To         Stephane Michaud
Subject    Re: Mark, Release in units

  SM>         I made a procedure in turbo pascal 6.0. it's a normal procedure
 SM> wich is in a unit.  In that procedure, it tried to use the mark and
 SM> release functions and it wouldn't compile.  Then I moved the content of

 SM> the procedure to the main file(not a unit) and it worked fine.

 SM>         Does this mean I can't use Mark and Release in a unit??? Is this
 SM>         a bug?? Am I doing something wrong???

Since Mark and Release are in the System unit, you should be able to use them
anywhere.  The most likely thing that went wrong is that your unit uses some
other unit that redefines Mark and Release in a way incompatible with the
standard definition.

What error message did you get?

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/19  08:58:30

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 09:07:48
From       Dj Murdoch
To         KEVIN PARADINE
Subject    Re: FEATURES LACKING IN T

  >The memory isn't any slower to access...  It is just that you have to
 >deal with the overhead of TP pointers...  For example, if you used
 >MOVEMEM, to different areas of memory (base 640k at least...) there
 >should not be any difference in speed.

 KP> Sure there would be.  You'd have to put differing values
 KP> in the segment registers as opposed to the 64k max model
 KP> of the stack frame.  Depending on the kind (and size) of
 KP> moves you made, this could be a significant amount of
 KP> additional time.   Remember that you are MOVing a maximum
 KP> of four bytes at a time, and probably less on a 286 or an
 KP> 8 bit machine.  Every time you move the bytes, you either
 KP> have to override the default segment or load a new value
 KP> into the segreg in question.  Either operation incurs
 KP> overhead, repeated possibly thousands of times, it amounts
 KP> to a significant delay.

You only change the segment registers once at the start, and restore them
at the end.  This lets you move 64K with only one change to the segment register
.  Unless you're talking about moving tiny blocks many times, it's not significa
t.

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/19  08:58:30

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 01:40:36
From       Trevor Carlsen
To         Matt Heck
Subject    sprache



 MH>     If you will notice, your pathetic hi-bit characters DO
 MH> NOT MAKE IT ACROSS THE NET!!! If you can't post in English,
 MH> GET OUTTA FIDONET, PAL!

Ok Matt... that does it.

You have now been formally warned both directly and also via your sysop at
least TWICE.  The next message (flame, such as above, off-topic etc) that
does not STRICTLY conform to the rules of this echo will see your access withdra
n WITHOUT further notice.

Consider this to be your final warning.

Trevor Carlsen
Moderator.

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/19  18:16:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 02:36:48
From       Trevor Carlsen
To         Stephane Michaud
Subject    Mark, Release in units



 SM> I made a procedure in turbo pascal 6.0. it's a normal
 SM> procedure wich is in a unit.  In that procedure, it tried to
 SM> use the mark and release functions and it wouldn't compile.
 SM> Then I moved the content of the procedure to the main
 SM> file(not a unit) and it worked fine.

 SM> Does this mean I can't use Mark and Release in a unit??? Is
 SM> this a bug?? Am I doing something wrong???

As you do not tell us what the compiler error was, it is almost impossible
to help you.  Why not prepare a demonstration so we can intelligently assess
your problem?

Mark and Release can be used anywhere.  Perhaps you are using a local variable
as the parameter.  This would only be OK if the Release call occurred within
the same scope.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/19  18:16:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 01:56:47
From       Trevor Carlsen
To         David G. Edwards
Subject    Re: Procedures...



 DG> such "standard" stuff should be done with regular proc's.
 DG> IMO, an exit proc should be as short and "clean" as
 DG> possible.

 TC> Why?  TP gives me the tool so I use it.  I have no qualms
 TC> about many different exit procedures - even perhaps one per
 TC> unit if it is justified!

 DG> Certainly if it's needed, do it!  Especially if it
 DG> complements initialization code.  I depend on symmetry to
 DG> understand my programs.

 DG> On the other hand, if it's not needed, I'd rather cleanup
 DG> not go into an exit proc since they're a little trickier to
 DG> trace into with the IDE.  I think the IDE won't break in an
 DG> exit proc unless a breakpoint is set in the exit proc.  (I
 DG> know-- you don't have the any problems with the IDE since
 DG> you don't use it. :-))

The rule-of-thumb I use regarding exit procedures is this - if there is code
that absolutely MUST be executed on program termination regardless of how
that termination is brought about then it goes in an exit procedure.

I do not use it as a convenience as I believe that would be sloppy and lazy
programming.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/19  18:16:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 02:04:54
From       Trevor Carlsen
To         Seamus Venasse
Subject    TP6.0 Problems



 SV> I have a question about Turbo Pascal 6.0 regarding use on an
 SV> 8088. Every time I compile a program to run from the IDE on
 SV> my Tandy 1000 SX (8088) it works fine.  The program does
 SV> what it was programmed to do. The problem occurs when the
 SV> program exits.  It freezes my computer. With the exact same
 SV> configuration, I cannot duplicate this on my 286 Zenith
 SV> laptop.  Has anybody else experienced this same problem on
 SV> an XT, or any other processor for that matter?

Does it freeze on the Tandy when run as a standalone program rather than from
the IDE?

Do the following:

Make sure that the compiler directive {$G-} is placed at the start of your
source code.  This ensures that no 80286 code is generated.  It is also the
default setting when you purchase TP6.

Turn range checking on. {$R+}

Recompile and execute... Still a problem?  If yes, then it would appear that
memory is somehow being overwritten.  Does the program use the heap and/or
pointers?  Does it use any interrupt routines?

Just before termination check that the value of ExitProc has not been changed
somehow.


TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/19  18:16:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 03:26:06
From       Trevor Carlsen
To         Gordon Tackett
Subject    Running Bat files from Pascal



 >      Does anybody know how to run *.BAT files from
 > Pascal? I am told that EXEC('....' etc.); only runs
 > *.EXE and *.COM programs. Any suggestions?
 >      thanx
 GT> EXEC('C:\COMMAND.COM','/cFILE.BAT');

What if he doesn't have command.com in the root directory? Or worse, what
if he doesn't have command.com?

:-)

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/19  18:16:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 08:07:57
From       Dj Murdoch
To         John Gohde
Subject    Re: A Virtuous Pascal ...

 DM>> Standard Pascal is, in my opinion, a far inferior language DM>> to Turbo
Pascal. (At least one of the academics I was DM>> talking to agreed with this,
but didn't see that a first DM>> programming course should teach a useful
language.)

 JG> Educational institutions are supposed to teach useful programming
 JG> styles; NOT  a particular useful  programming language. There  is
 JG> plenty of time for brand loyalty to develop, later.

There's no reason that you can't teach good style with a good language rather
than a bad one.

 JG> A college  can teach  COBOL, but  to teach  students that IBM 370
 JG> COBOL is better than HP 3000 COBOL would be absurd! I fail to see
 JG> why the same logic would not apply to Pascal.

I don't know COBOL, but if IBM 370 COBOL is better than HP 3000 COBOL, why
not teach that?  I'd guess there wouldn't be much difference; COBOL has been
standardized longer.  The same isn't true of Pascal.  There are large fundamenta
 differences between Turbo Pascal and Standard Pascal.  In almost all cases
those make TP a better language, IMHO.

Standard Pascal is very well suited to 70's ideas of structured programming,
but isn't nearly as good at modularity as TP is.

 JG> When  you can  not fool  with graphics,  you don't. Narrowing the
 JG> range of  possiblities simpilies the task  at hand. Simplicity is
 JG> certainly not a  virture of TP. Nor, is a long  attention spand a
 JG> common characteristic of todays youth.

I think instructors who teach standard Pascal have the same contempt for student
 as you do.  My students are adults; their time is valuable; some of them
are smarter than I am.  If I think something would be a waste of time for
me to learn I won't teach it to my students.

 JG> Further,  the  programming  EXAMPLES  Borland provides absolutely
 JG> stink  when it  comes to   programming style  (over use  of gobal
 JG> variables, for one)!

Why use Borland examples?

 JG> I can  see some  kid giving  his teacher  this lip: "But, Borland
 JG> does it this way, why can't I?"

If one of my students asked me that, I'd tell him/her.  If I couldn't give
a convincing reason why Borland was wrong, then why shouldn't s/he use that
style?



--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/20  15:45:09

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 08:25:37
From       Dj Murdoch
To         Markus Schanovsky
Subject    Re: Problems TPW-Debugger under Win 3.1

  MS> Dear Mates!
 MS> Sinve I am running Windows 3.1 the debugger of Turbo-Pascal for
 MS> Windows does not run - "CANNOT RUN WINDEBUG.DLL".
 MS> Who can help me?

Borland has put together some fixes to make it run in 3.1.  Look for TPWN31.*
on Compuserve, or on a Fidonet node that gets PDN Pascal, or on Internet,
on garbo.uwasa.fi.

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/20  15:45:09

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 08:28:38
From       Dj Murdoch
To         All
Subject    TP6BUGS6.ZIP hatched again

 It looks like something went wrong when I sent out my TP6 bug list a couple
of weeks ago.  (Thanks to John Giesbrecht for letting me know!)  I've hatched
another copy to PDN Pascal; I hope it works this time.

--- Msg V3.2
 * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/20  15:45:09

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 16:29:50
From       Mark Ouellet
To         Paul Farr
Subject    Re: Why I Like Tp 5.5 Ide


    On 15 May 92, you, Paul Farr, of 1:348/205.0 wrote...

 >>You too (about the pains with the search and replace)?  I kept
 >>complaining about it and not many people agreed with me.  Have you
 >> used
 >>the much better version in TP < 6.0?

 PF> I'm not sure what you mean, there is a version greater than 6.0 ?

Paul,
        < smaller than
        > greater than

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/20  15:45:17

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 16:35:45
From       Mark Ouellet
To         Arvel Hathcock
Subject    Re: Screen Save


    On 15 May 92, you, Arvel Hathcock, of 1:130/101.0 wrote...

 AH> I have a question about the screen save code posted a few days ago.
 AH>
 AH> I can't remember who the original poster of the code was so I had to
 AH> reply to your reply to him/her.  The code was something like:
 AH>
 AH> Var F:File;
 AH> Begin
 AH> Assign(F, Filename);
 AH> Rewrite(F,1);
 AH> BlockWrite(F, mem[$b800:0],4000);
 AH> Close(F);
 AH> end;
 AH>
 AH> I tried this and couldn't make it work.  It created a 4000 byte file
 AH> on disk which did contain the screen image but when I went to type
 AH> out the file (TYPE FILENAME.EXT), I got one character printed at a
 AH> time followed by a beep inbetween each character.

Arvel,
        What that file contains is the SCREEN memory which
contains not only caracters but also the attributes of those
caracters on the screen. The attributes tells how to display
the caracter ie: what forground color, background color and
intensity as well as if it's blinking or not.

        Since you got bells while typing it I can only
assume you dumped a Screen with WHITE colored caracters,
WHITE is color number 7, White caracter on black background
and 7 is also the ASCII code for a BELL thus you got 1
caracter, 1 attribute which happened to be white (7) and so
the bell rang.

        The screen is settup as 4000 bytes or 2000 pairs of
caracter/attribute. What you copied to the file was an IMAGE
of the screen.

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/20  15:45:18

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 16:46:37
From       Mark Ouellet
To         Greg Smith
Subject    Re: Soundblaster


    On 14 May 92, you, Greg Smith, of 1:104/60.0 wrote...

 DS>>SoundBlaster Hardware Infoamation.
 DS>>   1)  Digital to Analog Convertor (DAC)
 DS>>       -  Max sampling rate:24KHz in 8-bit, DMA mode.
 DS>>   2)  Analog to Digital Convertor (ADC)
 DS>>       -  Maxsamplingrate:13KHz in DMA mode

 GS> Do you have any info on the SB Pro?  It's got twice the sampling rate
 GS> (or 24Khz stereo).  Thanks for the info.

Greg,
Yake a look at ATI's STEREO-F/X or better yet their VGA
Stereo-F/X which I got.

        VGA card, 1024x768x256
                   800x600x32k
                   640x480x32k
                   800x600x256
                   etc....

        Drivers included for WINDOWS, ACAD, ACAD-386 etc...

        Fully Adlib/SB compatible
                STEREO same as SB PRO
                MONO 44KHz

        Comes with VOYETRA's SPjr

        JoyStick
        MIDI In, Through, Out
        LINE/MIC In
        Speaker Out.
        Comes with Speakers, MIDI breakout box which brings
        the VOLUME control to the front of the PC + all the
        above stated connections.

        BUS Mouse interface + 3 button mouse.

        ALL ON A SINGLE CARD, ALL IT LACKS IS THE CD-ROM
        INTERFACE CONNECTOR OF THE SB-PRO AND FRANKLY, WHO
        WANTS IT WHEN IT IS KNOWN TO BE COMPATIBLE WITH VERY
        FEW CD-ROM DRIVES.



And to get back on topic, it can be programmed in Pascal ;-)

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/20  15:45:18

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 17:21:36
From       Mark Ouellet
To         Ken Burrows
Subject    Re: packing bytes


    On 15 May 92, you, Ken Burrows, of 1:249/201.21 wrote...

 KB> So, with one donut, you can have 4 states.  1.) Choclate with hole.
 KB> 2.)Chocolate without a hole. 3.)Vanilla with a hole.  4.)Vanilla without

 KB> a hole. This means that you can represent two distict bytes with only a

 KB> single box of 8 doughnuts.
 KB>
 KB> All you have to figure out is how to program a 4 state bit.

Well Ken,
        At last, when the Hot weather hits, the term "CORE
MELT-DOWN" can apply to computers and not just nuclear
reactors.

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/20  15:45:18

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 00:00:00
From       Terry Hughes
To         Jud Mccranie
Subject    B-Tree Question


JM>In B-tree filer, a file is indexed on a secondary key.  I want to get
JM>all records that match a given key (typically 10 or 20).  Right now I'm
JM>finding the key, getting that record, repeating.  Would it be faster to
JM>do all of the key finds first (storing the ref numbers) and

Part of your message got garbled. What I quoted above is all
I got (that made sense).

However, I think I know what you're asking: is it faster to
loop collecting the reference numbers first or do a BTGetRec
after each BTNextKey? The answer is I don't think it would
make much of a difference at all. However, there may be some
advantage to collecting all the reference numbers first. The
issue is simply DOS buffers or caching issue. As you go
through the indexes, Filer may or may not have to read new
index pages in from disk. If it does and the paging
operation is mixed with the physical I/O required for the
BTGetRec calls then extra disk movement or caching flushes
may be required. If you do all the indexing seeking first
you minimize that possibility.

If my guess about the question was off just repost and I'll
try again.

-Terry


 * OLX 2.2 * TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss v1.00b on 92/05/21  08:06:58

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 00:00:02
From       Terry Hughes
To         Jeroen Pluimers
Subject    TP6 "bug"


JP>Hello Terry!

JP>28 Apr 92, Terry Hughes writes to Trevor Carlsen:

JP> TH> I assume OPCRT's Delay worked OK?

JP>Until version 1.11 of OPCRT the DelayMS routine is not
JP>correct for very fast machines. The DelayMS routine in
JP>version 1.11 is exactly the same as the one used in TP 6.0.

JP>I'm not sure if there is a new version of OPRO (this one is
JP>more than a year old, so I supsect there is) that fixes the
JP>problem.

We haven't made any changes to OPRO's Delay routines ever.
The routines in the current 1.14 version are the same as
they were back in 1.00. And, as you've noticed, they are
quite similar the TP6 routines listed in the RTL -- which is
why I was puzzled when Trevor reported that OPRO's worked
but TP6's didn't work.

Surprisingly, when I traced into the TP6 routines I noticed
those supplied in TURBO.TPL are different from those that
appear in the CRT.ASM file of the RTL. And those in
TURBO.TPL will definitely yield a higher "one ms iteration"
value than ours.

-Terry

 * OLX 2.2 * TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss v1.00b on 92/05/21  08:06:59

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 11:06:04
From       Terry Hughes
To         Gordon Tackett
Subject    AsyncPro bug


GT>Just though you might like to know that oopcom demo program
GT>has a small bug in it that if fixed will allow the program
GT>to work with opdrag (at least it did in my limited testing).
GT>I also removed the ifdef usedrag from ooui. If there is
GT>anything really stupid in doing this please let me know.

Thanks. We recently found that inconsistency while we were
doing some testing with the latest Analyst.

I didn't write OOPCOM so I don't fully understand the
rationale behind not allowing UseDrag. I know Rich, the
author of OOPCOM, started to implement dragging but later
decided against it. I'll check with him about your changes
to see if he thinks there might be a potential problem.

-Terry

 * OLX 2.2 * TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss v1.00b on 92/05/21  08:06:59

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 11:23:06
From       Terry Hughes
To         Bruce Ruona
Subject    Re: Compression


BR>I just picked up a copy of it the other day, Primarily for the compression
BR>ability, however, I was disappointed that yours suffers
BR>from the same problems I've found in 99% of the compression
BR>source codes I've looked at, namely lacking the ability to
BR>store more then one archive per file.  For example, using
BR>your stream unit to COMPRESS test.lzw *.pas {I Believe I
BR>have the syntax correct there?}

If you can't find routines that meet your need anywhere
else, you might want to know that the compression routines
that come with our commercial package Async Professional
include LHARC and ZIP compression routines that are capable
of storing more than one file per archive (in fact, we use
the standard LZH and ZIP archive formats).

-Terry

 * OLX 2.2 * TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss v1.00b on 92/05/21  08:06:59

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 00:00:08
From       Terry Hughes
To         Roger Joelsson
Subject    16550 chip


RJ> > Turbo Powers Async Pro has a Unit that does this.  I don't think

RJ>Do you think I could f'req it from you? Please do send some
RJ>net-mail about this if it's OK..

RJ>(I'm in real need of such a 16550 detector, and I've
RJ>searched here in Sweden, and the above software doesn't
RJ>seem to be available anywhere here.)

Async Professional is a commercial package (ours) so no one
is going to able to send you any parts of it. If you're
having trouble finding APRO in your area you might want
to give Grey Matter in England a call (0364-53499). Or you
can call us at the number below.

-Terry

 * OLX 2.2 * TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss v1.00b on 92/05/21  08:06:59

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 00:00:10
From       Terry Hughes
To         Seamus Venasse
Subject    Communications


SV>Does anybody have any specifications on TurboPower's
SV>TurboAsync?  The only thing I know about it is that is
SV>costs $100US.  The kinds of topics I'm looking for are:

SV>  * Baud support
SV>  * Comm port accessibility
SV>  * How many ports can be accessed at a time
SV>  * Protocol support
SV>  * Hardware support (handshaking)
SV>  * Ease of use

SV>Also, does anybody have a phone number for TurboPower?  The
SV>number I have, 1-800-830-9934, doesn't even work!  The
SV>recording says it is invalid...

APRO supports baud rates 300 through 115K. It supports
standard COM ports 1 through 8 plus lets you customize port
addresses for non-standard ports. You can open up to four
ports simultaneously. It provides the XModem/Ymodem family
of protocols, Kermit, Zmodem and ASCII. If offers hardware
flow control on CTS/RTS and/or DTR/DSR in normal or inverted
states.

My opinion on the ease of use of APRO is likely to be biased
since I'm the principal author -- however, most of the
feedback we get say we've struck a good balance between
power, flexibility and ease of use.

You can reach us at the number below or at 800-333-4160.

-Terry

 * OLX 2.2 * TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss v1.00b on 92/05/21  08:06:59

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 00:00:12
From       Terry Hughes
To         Gordon Tackett
Subject    Asyncpro


GT>I looked for the files oobplus and ooxport on you
GT>bbs...files not found. Could you place them on some BBS
GT>that is freqable.

No, but I'll make sure they get put on our BBS. Count on
them being there after 5/21/92 (my next day in the office).

-Terry

 * OLX 2.2 * TurboPower Software (voice 719-260-6641)

--- Maximus 2.01wb
 * Origin: The Programmers Playhouse (1:128/60)
 * Tossed by SFToss v1.00b on 92/05/21  08:06:59

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 08:05:08
From       Dj Murdoch
To         Jud Mccranie
Subject    Re: Impact Of .Tpu Size O

  JM> Not so with the CRT unit.  Just add it to USES and it will increase the
 JM> size of the EXE, even if you don't use anything in the CRT unit.

Adding a unit to the Uses clause means you're using the initialization section.
 In CRT, the init section calibrates Delay, does an AssignCRT on input and
output, and probably some other stuff.  That, together with the fact that
most of CRT is in one .OBJ block, means you get just about the whole thing
if you mention it.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:04

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 08:07:44
From       Dj Murdoch
To         David G. Edwards
Subject    Re: Borland, Os/2 2.0, And Yo

  DG> I've been wondering for some time if the IDE is trashing
 DG> my ctrl-break vector.  I do what's described above a lot,
 DG> and most of the time it's okay.  But every once in a while
 DG> (about twice a week), I'll notice (via a short program to
 DG> report it or a system crash) that ctrl-break points to
 DG> Never-Never land.  Then again, it may be me or my system.

I'm *sure* the IDE does nasty things with Ctrl-Break.  If you hit break while
running in Desqview, you're dead.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:04

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 08:09:03
From       Dj Murdoch
To         KEVIN PARADINE
Subject    Re: packing bytes

  >Is there any way to pack 2 bytes into one? If they were only like 2
 >coordinates, would it be possible to crunch them down to one? Some math
 >alogrythm or something? This would be very helpful.

 KP> Nope.  You'd need more than 2 bytes to get an effective
 KP> dictionary going. And if 2 bytes could be crunched down to
 KP> one, someone would have done it already.  The only way it
 KP> could work is if there were less than 4 bits of
 KP> information in each byte, but even then, how do you
 KP> delimit where it comes back apart again?  You don't.

A Huffman code often puts 2 bytes into one.  If you use a fixed code, you
won't need to store a dictionary.  If you want to play around with this, pick
up my Stream13.Zip unit from PDN Pascal, Internet garbo.uwasa.fi:/pc/turbovis/st
eam13.zip, or possibly BPROGA on Compuserve.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:04

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 08:12:57
From       Dj Murdoch
To         Trevor Ripple
Subject    Re: between integers

  TR> Okay, I understand a little bit about binary and hex.

 TR> But, I do not understand how to write a decimal.  Could someone do out
 TR> pi to 5 decimal points and show me the hex and binary versions?

There are lots of ways to store Pi, but you can write it fairly easily by
the following algorithm.

1.  Write out the whole number part, and subtract it off.  2.  Write out a
decimal point.  Loop: 3.  Double the result.  4.  Write out the whole number
part (either 0 or 1!), and subtract it off.  5.  Go back to 3.

If I do this on a calculator, I get

 11.00100 ...

To get hex, just group the binary in groups of 4 bits:

 3.2....

A harder question is how these things are stuffed into bytes when you store
a Real or Double or whatever.  Take a look in the TP Programmer's Guide for
details on that.
--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:04

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 08:19:30
From       Dj Murdoch
To         Bruce Ruona
Subject    Re: TVISION RESOURCE Files?

  BR>
 BR> using a turbo vision resource file, would it be possible
 BR> to store an object and all its assorted
 BR> procedures/constructors/inits/etc within the actual resource file?

You can't.  Turbo Vision only allows you to put data into resource files,
not code.

 BR> I HAVE been able to store the object in a resource file,
 BR> but how do I register the object type, and call the init
 BR> procedure without having the type definitions in my main
 BR> program--of course having the type definitions, but not
 BR> the actual routines in the main program leads to Undefined
 BR> forward compiler errors 8-(

Put the object definition in a unit, and have your main program Use the unit.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 08:21:32
From       Dj Murdoch
To         John Meyers
Subject    Re: Disk Serial Numbers In dos 5.0

  JM> Is there a way I can read a volume serial number from a
 JM> disk?  I pulled apart the boot sector of a floppy and
 JM> found what formated it,the volume label, and the fat type
 JM> but not the serial numbers.  I have routines to read and
 JM> write volume labels but I need the disk serial number.  Any ideas?

DOS Service 440D gives it to you.  I posted a how-to message under the subject
"Reading the boot sector" yesterday.  If you missed it, grab any good DOS
reference, e.g. Ralf Brown's interrupt list.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 22:14:46
From       Mark Ouellet
To         Gordon Tackett
Subject    Re: Multiuser databases


    On 15 May 92, you, Gordon Tackett, of 1:352/777.42 wrote...

 >> Derek,
 >>         Take a look at.... OOPS MEMORY LAPS.. what's
 >> that
 >> darn flying horse's name..Oh yeah, PEGASUS, full E-
 >> Mail
 >> system for NetWare with file enclosure etc... and it's
 >> free-ware.

 >>         Best regards,
 >>         Mark Ouellet.

 GT>
 GT>
 GT> I would like to look at this program as well would you know where it is

 GT> freqable and what the filename is?

Gordon,
        I just had a look at my Binkley logs up to Nov 1990
and I didn't see it there so it was either before that or I
got it at the office. In any case I remember seing a newer
version announced a while back. I should have a copy
somewhere on my tapes, I'll have a look and let you know.

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 22:22:11
From       Mark Ouellet
To         Dj Murdoch
Subject    Re: Help - Reading Records At


    On 17 May 92, you, Dj Murdoch, of 1:221/177.40 wrote...

 DM> I prefer using streams for this sort of thing, because you automatically

 DM> get a 1 byte record size, and error checking is easier.

 DM> I'd use:
 DM>
 DM> My_stream := New(PBufStream, init('Clients.dbf',stOpenRead, 2048));
 DM> My_stream^.read(My_Header,sizeof(My_header));
 DM> if My_stream^.status <> stOK then
 DM> { handle the error }
 DM>
 DM> The advantage of this approach (besides being a little shorter) is that

 DM> it's likely to be a lot faster:  you don't get buffered I/O on untyped

 DM> files.

 DM> Watch out here - your Offset_Of_Record is going to be incorrect if it's

 DM> out further than 64K.  A safer calculation is
 DM>
 DM> Offset_of_record := sizeof(One_Header) +
 DM> LongMul(Record_To_Get*Bytes_To_Read);
 DM>
 DM> A disadvantage is that streams and LongMul are only available in TP 6

 DM> and later.

Thanks for the tip Dj,
        It does seem interresting allthough I never played
with Streams yet, thought they looked complicated, your
example made it look a lot simpler than I thought.

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 23:16:52
From       Mark Ouellet
To         Joshua Kersey @ 930/22
Subject    Re: TSR


    On 16 May 92, you, Joshua Kersey @ 930/22, of 1:10/8.0 wrote...

 JK> -/----- Mark Ouellet said to Jason Davies -----\-
 JK>
 MO>>         Well since error #6 is "Bad file handle" I suspect
 MO>> you open the file during initialisation of the TSR and the

 JK> I've come across this error before. the Borland help file says "This

 JK> error should not occur", yet it DOES! My problem was attempting to open

 JK> the file more than once.

Joshua,
        it may be so but TSRs are a special case, I would
suspect the effect is not only to close the file but also to
clear the handles. That is one reason why people wondered
for a long time how PRINT did it.

        When you say your problem was attempting to open the
file more than once, do you mean without closing it in
between???

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 23:20:42
From       Mark Ouellet
To         Ken Burrows
Subject    Re: Help - Reading Records At


    On 16 May 92, you, Ken Burrows, of 1:249/201.21 wrote...

 KB> My solution, and it is only a suggestion, would be to read in the old

 KB> record as is, and then extract whatever info I want from it.
 KB>
 KB> Type
 KB> TheRest = Whatever it is that you are reading;
 KB> OldData = Record
 KB> trash : Array[1..255] of byte;
 KB> data  : TheRest;
 KB> end;
 KB>
 KB> Var
 KB> InBuffer : OldData;
 KB> IWant    : TheRest;
 KB>
 KB> while not eof(thefile) do
 KB> Begin
 KB> BlockRead(thefile,InBuffer,SizeOf(InBuffer),result);
 KB> if Result = SizeOF(InBuffer) then IWant := InBuffer.Data;
 KB> End;

Ken,
        One problem with this is that the Header is NOT
padded to a record's length thus reading 331 bytes the first
time will in fact get the 255 bytes of the header + 78 bytes
from the first record. From that point on your reads and
writes will allways be offset +/- 78 bytes into the next or
previous record.

        Making it a FILE OF <HEADER> or a FILE OF <RECORD>
does not work since they are of different sizes you will
never be able to synchronize the reads for subsequent
records on Record boundaries.

        That is why you MUST open the file with a 1 byte
record size to be able to seek to a record taking into
acount the offset created by the header.

        Dj did give an elegant use of TP 6.0's Streams to
achieve this in his reply to me a few messages back.

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-19-92 23:27:51
From       Mark Ouellet
To         Seamus Venasse
Subject    Re: TP6.0 Problems


    On 15 May 92, you, Seamus Venasse, of 1:17/67.4 wrote...

 SV> I have a question about Turbo Pascal 6.0 regarding use on an 8088.
 SV> Every time I compile a program to run from the IDE on my Tandy 1000 SX

 SV> (8088) it works fine.  The program does what it was programmed to do.

 SV> The problem occurs when the program exits.  It freezes my computer.

 SV> With the exact same configuration, I cannot duplicate this on my 286

 SV> Zenith laptop.  Has anybody else experienced this same problem on an XT,

 SV> or any other processor for that matter?

Seamus,
        Would you by any chance be using an exit procedure
which is part of a Unit compiled with 286 instructions
forced on. They will hang on an 8088.

        You see you said EXACT SAME CONFIGURATION while one
is an 8088 and the other is a 286 !!! ;-)

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-20-92 00:04:15
From       Mark Ouellet
To         Lars Ladingkaer
Subject    Re: Programming Adlib/Soundblaster [1/6]


    On 08 May 92, you, Lars Ladingkaer, of 2:234/97.5 wrote...

 LL> Hello All!
 LL>
 LL> Many of you have asked for some docs on how to program
 LL> Adlib/Soundblaster.
 LL> This will help with the low-level programming of the cards.
 LL> Note: There are 6 messages!
 LL>
 LL> ============================== cut here
 LL> ====================================

Lars,
        Same thing here, only 1, 4 & 6 made it through.

        Best regards,
        Mark Ouellet.



--- ME2
 * Origin: One BEER gets me drunk.... usualy the 47th ;-) (Fidonet 1:240/1.4)
 * Tossed by SFToss v1.00b on 92/05/21  14:05:12

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-21-92 01:11:18
From       Trevor Carlsen
To         Dave Blaser
Subject    Overlay files?!



 TC> You do not say which TP version you own.  If TP4 then you
 TC> are out of luck as there are no overlays in that version.
 TC> If you own later versions then the manual contains a
 TC> complete chapter with a full explanation of what is
 TC> required.  So maybe you should RTFM!

 DB> Sorry, I've got TurboPascal v6.0, oh and I can't RTFM due to the fact

 DB> that the gentlemen who gave me the TurboPascal 6.0 disks, had lost the

 DB> manual for it.

*IF* you have a legal copy, phone Borland to order a replacement.

TeeCee



--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/21  19:06:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-21-92 02:02:53
From       Trevor Carlsen
To         James Cook
Subject    Re: Pascal style #2



 JC> I think when this question was originally posed, the poser didn't want

 JC> size or speed of execution to be taken into account.  I have to admit,

 JC> there are situations where the tighter code may be harder to read (ie

 JC> Example 3), but most of us write our own source and re-write our own

 JC> source.  I guess what I'm trying to say is, even though TeeCee's
 JC> semi-cryptic if-then incarnation, as long as he is the only one
 JC> editing his code and he uses this construct quite often, there is no

 JC> harm!

 JC>   Example A:
 JC>         X := 1;
 JC>         If Y > 10 then X := 2;

 JC>   Example B: (this would be the one I use and the indentation I
 JC> prefer)
 JC>         If Y > 10 then X := 2
 JC>                   else X := 1;

 JC>   Example C:
 JC>         X := Succ (Ord (Y > 10));

 JC>         Example A               Example B               Example C
 JC>          19 bytes                21 bytes                14 bytes

Your comments are closer to the mark than any of the others in regards to
Example C.  Without exception the criticism of that method is the fact that
it is harder to understand.  I agree - but an important fact seems to be overloo
ed, that is, if it is the best on all counts except readability then there
should be no problem, as that is one of the reasons we have comments.
So -

   x := succ(ord(Y > 10);  { if y > 10 then x := 2 else x := 1; }

Any code that may be hard to understand should be commented in such a way
so as to make it easier to understand.  In a team or commercial environment
that is an iron clad rule.  When two coding methods have no difference in
speed or size efficiency *then* IMHO the more cryptic version should be discarde
 in favour of the more readable.


TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/21  19:06:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-21-92 01:51:55
From       Trevor Carlsen
To         Lars Ladingkaer
Subject    Programming Adlib/Soundblaster [1/6]



 > Note: Reposted due to some unknown errors in the link.

Lars, you can repost these messages until doomsday!  As it stands many systems
will ALWAYS miss out on two or three of them because they will have been discard
d as dupes somewhere along the line.

When posting multiple message sequences it is important that the "[1/6]" "[2/6]"
etc portion of your subject line be placed first, not last, on that line.
 Many dupe detectors only look at the first 20 or 30 characters of the subject
line and if two messages can be processed within the same clock tick by your
mailer, then they get the same MSGID or EID number and never make it into
the net, or if they do, are discarded somewhere along the line.

BTW only numbers 1,2 and 5 made it this time!

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/21  19:06:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-21-92 01:54:50
From       Trevor Carlsen
To         Brian Stark
Subject    RE: UNIX STYLE TIMESTAMP



 > Having said that, the above function is incorrect!  It should read

 > IsLeapYear := ((Source mod 4 = 0) and (Source mod 100 <> 0)) or
 >               (Source mod 400 = 0);
 BS> Are you sure?? The function was given to me by a college professor
 BS> (gulp).

Yes I am sure!  :-)  However as I pointed out, it is really only of academic
interest as using longints for unix timestamps can only be valid for the years
1970-2038 anyway and therefore all years between those two dates that are
divisible by 4 are leap years.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/21  19:06:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-18-92 20:35:00
From       Norbert Igl
To         Paul Bamford
Subject    Direct Addressing of Video Memory. A cry





{> I am currently trying to write a Turbo Pascal program which performs
 > the following tasks:

 > (1) Get the address for video memory;}

   uses crt;
   var base : word;
       VidPtr : pointer;
       ScrFil : file;
   begin
     if lastmode = 7
        then base := $B000    { mono }
        else base := $b800;   { colour }
{ > (2) Convert this address to a pointer;}
        VidPtr := Ptr(Base, 0);
{ > (3) Copy the contents of the screen to a file of whatever type }
{ >     corresponds to the pointer assigned to the video address;}
       Assign(ScrFil, 'Save.Scr');
       Rewrite(ScrFil, 1);
       BlockWrite(ScrFil, VidPtr^, 4000 );  { 4000 = 80x25x2 (Chr+Att)}
       Close(ScrFil);

       ClrScr; { say what...}

{ > (4) At a later stage, copy the file contents back to screen. }

       Reset(ScrFil,1);
       BlockRead(ScrFil, VidPtr^, 4000);
       Close(ScrFil);
    end.
   ... any questions left ? (:-))

Bye from Germany, Norbert



---
 * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
 * Tossed by SFToss v1.00b on 92/05/22  11:06:31

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-21-92 21:52:00
From       Norbert Igl
To         Gerald Gutierrez
Subject    Detecting ANSI ?





Hi Gerald....

Function AnsiSysInstalled: boolean;
var _AX: word;
begin
  asm  mov ax, $1a00
       int 2f
       mov _ax, ax
  end;
  ANSISsyInstalled := Lo(_AX) = $FF
end;


Bye from Germany, Norbert

---
 * Origin: STOP READING! You're leaving the MSG-sector (2:241/5300.3)
 * Tossed by SFToss v1.00b on 92/05/22  11:06:31

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 02:17:36
From       Trevor Carlsen
To         Jud Mccranie
Subject    Re: The Function "Pos"



 JL>> It's not good to assign the value to the function until the
 JL>> end of the function, therefore it would be better to use a
 JL>> tempstr and assign upstring to tempstr outside of the loop.
 TC> I'm willing to listen to arguments on your reasoning but just
 TC> making such a statement without a reason does nothing to
 TC> convince me! Why is it not good?

 JM> In this case, it doesn't matter much, but I think he has a point in
 JM> general.  Without using a temp variable for the function value, you
 JM> can't reference it within the function:

 JM> funciton f : string;
 JM> begin
 JM> f := '';
 JM> ....
 JM> if f ....
 JM> end;

That's fine and I agree with you but it had no relevance to the function I
demonstrated and that is why I queried the statement.  Observing some GPP
just because something might happen when the nature of the code in question
makes that something impossible is of questionable logic to say the least.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 05:27:02
From       Trevor Carlsen
To         Joy Mukherjee
Subject    C conversion / V7 NodeL.



 JM> function CompAddress (ALine, Desire : Str160; L : Byte) : Integer;

 JM> label 99;

 JM> type
 JM>     NodeType = record
 JM>         Len   : Byte;
 JM>         Zone  : Word;
 JM>         Net   : Word;
 JM>         Node  : Word;
 JM>         Point : Word;
 JM>      end;

 JM> var
 JM>     Key     : NodeType absolute ALine;
 JM>     Desired : NodeType absolute Desire;
 JM>     K       : Integer;

 JM> begin
 JM>     Word (K) := Key.Zone - Desired.Zone;
 JM>     If K <> 0 then goto 99;
 JM>     Word (K) := Key.Net - Desired.Net;
 JM>     If K <> 0 then goto 99;
 JM>     Word (K) := Key.Node - Desired.Node;
 JM>     If K <> 0 then goto 99;
 JM>     If L = 6 then Key.Point := 0;
 JM>     Word (K) := Key.Point - Desired.Point;
 JM> 99:
 JM>     CompAddress := K;
 JM> end;

 JM> Egad!  It uses a GOTO!!!!  Before I get the usual hatemail and the
 JM> like, I would like your opinion on the best way to either avoid the
 JM> GOTO or rewrite the procedure.  In C, (and I apologize to all for the

 JM> obCenities in this message) the line is similar to :

 JM> if (k) return (k)

 JM> Since there is no Pascal equivalent to a return command, what
 JM> alternatives do I have???

 JM> Next, notice the type casting in the above.  With range checking on
 JM> and without the typecast, this will result in an RunTime Error 201.

 JM> Why is this??  K is defined as an integer, and the result of two words

 JM> being subtracted will often result in a negative, so why will it error

 JM> out?

With a couple of minor changes this becomes a natural for recursion. You don't
define just what a type str160 is so this can be done by making the first
two paramters untyped and thus you could call the function so -

  Whatever := CompAddress( ptr(seg(var1),ofs(var1)+1)^
                           ptr(seg(var2),ofs(var2)+1)^, L, 0);

If the first two paramters are strings then the pointer contortions can give
way to -

  Whatever := CompAddress(var1[1],var2[1],L,0);

Here is the function as I would suggest you write it -

function CompAddress (var ALine, Desire; L,count : Byte) : Integer;

  type
    NodeType = record
                 FirstWord,
                 NextWord   : word;
               end;
  var
    Key     : NodeType absolute ALine;
    Desired : NodeType absolute Desire;

  begin {$R-}
    if (Key.First = Desired.FirstWord) and (count <  3) then begin
      inc(count)
      CompAddress(Key.NextWord,Desired.NextWord,L,count);
    end else begin
      count := 3;
      If L = 6 then
        Key.FirstWord := 0;
    end;
    CompAddress := Key.FirstWord - Desired.FirstWord;
    {$R+}
  end;

Initially call with the third parameter set at zero.  Obviously untested,
although I think it should work, and as written above would require extended
syntax (TP6 only).

The reason you were getting range check errors was because there must be occasio
s happening when the possible return value of the subtraction was outside
the bounds for an integer.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 04:01:04
From       Trevor Carlsen
To         Florian Stupperich
Subject    HELP! CRT - Window() replacement



 > There is nothing that stops you from using write/writeln in a
 > window.  In fact that is all you can use if you want to remain
 > inside the window co-ordinates.  Perhaps I am misunderstanding
 > what it is that you seek?

 FS> i will use ANSI also, so that a can't use the CRT-Unit, that is
 FS> the problem. Do you have any idee ?

Then you have to parse the ANSI control sequences and change the attributes
as required before doing a write.  This is fairly complex and there are units
that will do this for you.  Look for a file called PANSI*.* on a BBS near you.


TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 04:32:44
From       Trevor Carlsen
To         Josh Lippy
Subject    Re: fsearch();



 JL> {$I-}
 JL> reset(infile);
 JL> {$I+}
 JL> if(ioresult <> 0) then begin
 JL>   writeln('Error opening file.');
 JL>   halt(1);
 JL>   end
 JL> else
 JL>   writeln('Open successful, continuing.');

 JL> Turning I/O checking off allows you to check to see if the open
 JL> worked, ...

True...

 JL> ... then you  turn it back on to use the file.  ...

This can be done but it is better to leave it off and check IOResult after
each I/O operation.

 JL> ... It's not truly reset when I/O checking is off,
 JL> so you still need to reset() once you get ready to
 JL> process.

This is incorrect.  If the reset worked, regardless of whether I/O checking
is on or off, file operations can commence without another reset.  All the
compiler directive {$I-} does is prevent  the generation of I/O error checking
code at compile time and thus at run-time, if an I/O error occurs,the program
continues on its merry way without generating a run-time error.  Because of
this it is imperative that the programmer check the IOResult function after
each I/O operation that could generate an error, in order to determine if
an error occurred and, if so, take appropriate action.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 04:09:13
From       Trevor Carlsen
To         Josh Lippy
Subject    Re: HangUp



 JM> I have your HangUp ultil for Tg and I noticed a problem...

 JL> HangUp is supposed to be run as an event...

This is unrelated to the conference topic.  Take it to netmail.

Trevor Carlsen
Moderator.

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 04:13:59
From       Trevor Carlsen
To         Fred Burgess
Subject    TG Source



 FB> I have the TG-X code and it compiled.  Maybe you got a copy that
 FB> somebody else hacked.  I also have the 2.5g code.  2.5j was never
 FB> released, not even the EXE was released.  Telegard 2.5k was released

 FB> as a beta only, and they hacked the EXE's.  Not nice.  Anyway, back on

 FB> topic, the source out right now for TG is 2.5g and 1.6a.  Rumor has it

 FB> the 2.7 is out, but I think that it's 2.5i hacked more.

I fail to see how you are "back on topic".  Discuss this by netmail please
or take the thread to an appropriate conference.  The subject matter of this
conference is Pascal.

Trevor Carlsen
Moderator.

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 06:51:05
From       Trevor Carlsen
To         Bruce Ruona
Subject    Re: Compression



 BR> Yes, normally I would use a third party compression utility, except in

 BR> this case I'm attempting to use the compression as part of my data
 BR> security routines as well as reducing data size (of course!) for a
 BR> clients system for transferring daily sales figures between offices.

 BR> using a third party compression routine would still give the client
 BR> possible access to the raw data.  Note that I did NOT program the
 BR> software that generates the data, I'm just assisting in transferring

 BR> the data, so I can NOT add a simple data encryption routine.

Because this type of application tends to have a similar format every day,
the ideal way to do this is to create a token table with all the commonly
used phrases and reports replaced by tokens.  The actual data be easily incorpor
ted into this and then the whole thing is reversed at the receiving end.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:33

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 17:18:43
From       Trevor Carlsen
To         Robert Johnston
Subject    Quick Question



 RJ> I have tried this MANY times before.  I have moved EVERYTHING
 RJ> that I could into the TPU  NUKEWARS.PAS  (overlay)  but the rest
 RJ> interfaces with my DATA FILES

Create a globals unit and have every unit that needs access to the global
variables in that unit use it.  eg

unit globals;

interface

var
...place all your global variables here.

implementation

end.

Then place the line "uses globals; "  in all the units your program uses that
need acces to any of the variables in globals.


TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:34

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 17:26:50
From       Trevor Carlsen
To         Mike Copeland
Subject    TP Smart Linking



 MC> Smart Linking - to the effect that variables "grouped" under a "Var"

 MC> statement are not culled out if they aren't referenced.  Does that
 MC> mean (in the extreme case) that putting a "Var" on _every_ variable in

 MC> a global data unit will produce the minimum-sized object EXE program?

 MC> And that a _single_ "Var" will in turn not reduce the program variable

 MC> space at all?

Look up "Smart linking" in your manual.

"The removal of unused code takes place on a per procedure basis; the removal
of unused data takes place on a per declaration section basis."

Also:

"When compiling to memory, Turbo Pascal's smart linker is disabled. This explain
 why some programs become smaller when compiled to disk."

Another point to remember is that any reference to code or data in an .obj
file that is needed in any unit results in ALL the code and data from that
unit being linked in, regardless of whether or not it is used.  This explains
why the crt unit adds so much code to any program as it has one const declaratio
 section, one var declaration section and only one .obj file that ALL the
procedures and functions appear in.  The initialisation section then uses
one of those procedures (AssignCRT) and so the whole lot gets linked in.

TeeCee

--- TC-ED   v2.01
 * Origin: The Pilbara's Pascal Centre ([phone]) (3:690/644)
 * Tossed by SFToss v1.00b on 92/05/23  08:20:35

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 08:18:44
From       Dj Murdoch
To         Mike Copeland
Subject    Re: Pascal style #2

  MC>    The most important thing, I believe, is to have a consistent style.

That's so true.  I think it's so important that I develop a new consistent
style about every 6 months :-).

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/23  08:21:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 08:20:07
From       Dj Murdoch
To         Jud Mccranie
Subject    Re: Pascal Style #2

  JM> You could have

 JM>   x := 9999 * ord( y <= 0) + 1

 JM> but that is the sort of thing I did 10 years ago when I thought I was
 JM> being so clever.  Sure, it gets it on one card (line), but it is hard
 JM> for the programmer to read, understand, or modify.  The programmer can
 JM> look at the first and see immediately what is happening.  In the second

APL programmers wouldn't blink an eye when they saw that.  They'd think they're
back home!

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/23  08:21:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 08:23:12
From       Dj Murdoch
To         Greg Smith
Subject    Re: Impact Of .Tpu Size O

  GS> That's because of the CRT unit's initialization code.  It includes some
 GS> code right there to calabrate the delay procedure etc.. Plus the input
 GS> and output file variables along with their supporting procedures are
 GS> included since they're assigned in the init code.  Not all of the unit
 GS> is linked in, however, the parts which are obviously not used are left
 GS> out.  (That's why "smart" is in quotes, it's better than nothing but is

 GS> still pretty dumb).

With the CRT unit, that's not true.  It only has two code blocks:  the initializ
tion section, and everything else.  Since the init code references some of
the other stuff, you get the whole shebang when you put CRT in your Uses list.



--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/23  08:21:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 08:26:26
From       Dj Murdoch
To         Mark Ouellet
Subject    Re: Help - Reading Records At

  DM> Watch out here - your Offset_Of_Record is going to be
 MO> incorrect if it's
 DM> out further than 64K.  A safer calculation is
 DM>
 DM> Offset_of_record := sizeof(One_Header) +
 DM> LongMul(Record_To_Get*Bytes_To_Read);

Oops, I made a typo there - that should be

  LongMul(Record_To_Get,Bytes_To_Read)

 MO> Thanks for the tip Dj,
 MO>         It does seem interresting allthough I never played
 MO> with Streams yet, thought they looked complicated, your
 MO> example made it look a lot simpler than I thought.

I think the manual makes them look unnecessarily complicated.  If you skip
over the object registration and Put and Get, they're really no more complicated
than any other binary file.

--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/23  08:21:05

▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄

Conference 4
Date       05-22-92 08:32:25
From       Dj Murdoch
To         Mike Copeland
Subject    Re: TP Smart Linking

  MC>    Dj, a few weeks ago you posted a statement about
 MC> variables and Smart Linking - to the effect that variables
 MC> "grouped" under a "Var" statement are not culled out if
 MC> they aren't referenced.  Does that mean (in the extreme
 MC> case) that putting a "Var" on _every_ variable in a global
 MC> data unit will produce the minimum-sized object EXE
 MC> program?  And that a _single_ "Var" will in turn not
 MC> reduce the program variable space at all?
 MC>    I haven't tried it yet, and I'm thinking of doing so.
 MC> It seems to me (if this is true) that an intelligent
 MC> reordering of variables in a global unit would benefit
 MC> most programs which use it.  Is that right?
 MC>    Constants, too?

I think that's usually a good idea.  You might find that linking slows down,
you'll certainly find that your .TPU gets bigger, but generally your program
should use less data segment space if you group both global Var declarations
and typed Const declarations according to usage.

You can take it too far, though.  If you're really tight for space, you might
use $A- to turn off word alignment.  However, Var and Const blocks are *always*
word aligned.  For example:

  Var
    b : byte;
    w : word;

would take up 4 bytes with $A+, but only 3 bytes with $A-.  However,

  Var
    b : byte;
  Var
    w : word;

would always take up 4 bytes regardless of alignment.

My own practice (when I think of it) is to group variables by functionality.
 If I have several variables that are all dealing with the same issue, I'll
put them in one block.  If some other variables serve a different purpose,
they go in a different block.  Then I can pick or choose functions from the
Unit and only get the variables that matter.

I didn't quite follow this rule in my Streams unit, which is a real mishmash
of different functions.  There I was very careful to separate declarations
so that you get the minimum allocation.  This makes the source code pretty
ugly in some places; for example:

const
  ForSpeed : TStreamRanking = (RAMStream, EMSStream, XMSStream, FileStream);
  { Streams ordered for speed }

const
  ForSize : TStreamRanking = (FileStream, EMSStream, XMSStream, RAMStream);
  { Streams ordered for low impact on the heap }

const
  ForSizeInMem : TStreamRanking = (EMSStream, XMSStream, RAMStream, NoStream);

  { Streams in memory only, ordered as #ForSize#. }

const
  ForOverlays : TStreamRanking = (EMSStream, XMSStream, FileStream, NoStream);

  { Streams ordered for speed, but never in RAM. }

The typical user would only need one of these constants, so they're all in
separate blocks.


--- Msg V3.2
 * Origin: Murdoch's_Point  - -   (1:221/177.40)
 * Tossed by SFToss v1.00b on 92/05/23  08:21:05